Компания Oracle несколько дней назад выпустила новую версию своей платформы виртуализации VirtualBox 4.1, где появилось множество нововведений и улучшений, при этом ветка VirtualBox 4.0.x все еще продолжает поддерживаться.
Новые возможности VirtualBox 4.1:
Virtual Machine clones: VirtualBox поддерживает функции клонирования виртуальной машины путем дублирования виртуального диска и настроек ВМ. Также генерируется новый MAC-адрес.
Linked Clones: помимо поддержки полных клонов, также появилась поддержка связанных клонов (linked clones), которые удобно использовать при разработке и тестировании, когда требуется экономия дискового пространства.
Larger memory support: VirtualBox поддерживает хосты с оперативной памятью до 1 ТБ.
Remote access: VirtualBox позволет использовать доступ к виртуальным машинам хоста по протоколу RDP за счет механизма VRDP. Также есть поддержка transport layer security (TLS) и серверной аутентификации VRDP для предотвращения атак типа "man in the middle".
Multiple monitors: для консоли виртуальной машины теперь поддерживается несколько мониторов.
New driver for Windows 7: Oracle разработала новый драйвер Windows Display Driver Model (WDDM) для гостевых ОС Windows 7 guests, который устанавливается вместе с guest additions и позволяет обеспечить поддержку прозрачности и 3D-эффектов в виртуальном ПК. Драйвер находится в статусе experimental.
UDP tunnelling: в VirtualBox 4.1 появился новый тип сетевого взаимодействия между виртуальными машинами и хостами. Это расширение host-only networking на группу физических хостов. То есть виртуальные машины на нескольких хостах взаимодействуют только между собой, но не видны во внешней сети.
Mac OS X Lion support: поддержка последней версии Mac OS X в качестве хостовой ОС.
Полный список изменений VirtualBox 4.1 доступен по этой ссылке. Скачать VirtualBox 4.1 можно здесь.
Пало-Альто, Калифорния, 1 августа 2011 – Компания VMware, мировой лидер в области виртуализации и облачных инфраструктур, представила VMware vSphere Storage Appliance - новое программное решение, которое откроет богатые возможности платформы VMware vSphere по обеспечению непрерывности бизнеса и автоматизированному управлению ресурсами представителям малого и среднего бизнеса (СМБ). Это станет возможным без особых затрат и сложностей, связанных с использованием совместных хранилищ. Таги:
Теперь пришел черед VMware vCloud Director 1.5, продукта который позволяет построить платформу облачных вычислений для частных облаков на базе VMware vSphere 5 (см. наши упоминания тут и тут).
Напомним вкратце что это такое и для чего нужен vCloud Director. VMware vCloud Director - это надстройка над инфраструктурой vSphere, которая позволяет создавать безопасные (vShield 5) гибридные облака с поддержкой нескольких арендаторов путем объединения ресурсов инфраструктуры в виртуальные ЦОД. Ресурсы этого датацентра предоставляются по требованию (см. vCloud Connector) в рамках определенного рабочего процесса.
vCloud Director объединяет ресурсы ЦОД (вычислительные ресурсы, хранилище и сеть) и соответствующие политики в виртуальные ЦОД. Полностью инкапсулированные многоуровневые виртуальные сервисы пользователей предоставляются в виде объектов vApp в формате OVF (наборы ВМ для одной задачи). Конечные пользователи и соответствующие политики объединяются в организации. Компоненты инфраструктуры, пользователи и услуги объединяются в логические пулы (управляются на основе политик), которые соответствуют определенным уровням обслуживания.
В vCloud Director есть каталог уже готовых стандартизированных приложений в ВМ, которые готовы к развертыванию со стороны пользователей (через портал самообслуживания). Эти vApp предоставляются как услуга на базе платы за использование (Pay as you go).
Чтобы лучше понять для чего нужен и как устроен VMware vCloud Director нужно посмотреть вот эту презентацию:
А теперь о новых возможностях VMware vCloud Director 1.5. Общая картина:
Появилась поддержка связанных клонов (Linked Clones) для выделяемых ВМ:
Появилась возможность кастомизации гостевых ОС и свойств шаблона OVF для автоматизации развертывания новых сервисов и их автоматической постконфигурации:
Появилась интеграция с различными Enterprise-системами за счет механизма vCloud Messaging в vCloud API:
Ну и вкратце остальные возможности:
Интеграция с распределенным коммутатором Cisco Nexus 1000V
Поддержка Microsoft SQL Server в качестве БД
Интеграция с vShield Edge VPN
Ну и, конечно, поддержка VMware vSphere 5
VMware vCloud Director 1.5 будет доступен в 3-м квартале 2011 года, вместе с VMware vSphere 5, по цене от $150 за виртуальную машину.
Вместе с релизом продуктовой линейки VMware vSphere 5, VMware SRM 5 и VMware vShield 5 компания VMware объявила о выходе еще одного продукта - VMware vSphere Storage Appliance. Основное назначение данного продукта - дать пользователям vSphere возможность создать общее хранилище для виртуальных машин, для которого будут доступны распределенные сервисы виртуализации: VMware HA, vMotion, DRS и другие.
Для некоторых малых и средних компаний виртуализация серверов подразумевает необходимость использовать общие хранилища, которые стоят дорого. VMware vSphere Storage Appliance предоставляет возможности общего хранилища, с помощью которых малые и средние компании могут воспользоваться средствами обеспечения высокой доступности и автоматизации vSphere. VSA помогает решить эти задачи без дополнительного сетевого оборудования для хранения данных.
Кстати, одна из основных идей продукта - это подвигнуть пользователей на переход с vSphere Essentials на vSphere Essentials Plus за счет создания дополнительных выгод с помощью VSA для распределенных служб HA и vMotion.
Давайте рассмотрим возможности и архитектуру VMware vSphere Storage Appliance:
Как мы видим, со стороны хостов VMware ESXi 5, VSA - это виртуальный модуль (Virtual Appliance) на базе SUSE Linux, который представляет собой служебную виртуальную машину, предоставляющую ресурсы хранения для других ВМ.
Чтобы создать кластер из этих виртуальных модулей нужно 2 или 3 хоста ESXi 5. Со стороны сервера VMware vCenter есть надстройка VSA Manager (отдельная вкладка в vSphere Client), с помощью которой и происходит управление хранилищами VSA.
Каждый виртуальный модуль VSA использует пространство на локальных дисках серверов ESXi, использует технологию репликации в целях отказоустойчивости (потому это и кластер хранилищ) и позволяет эти хранилища предоставлять виртуальным машинам в виде ресурсов NFS.
Как уже было сказано, VMware VSA можно развернуть в двух конфигурациях:
2 хоста ESXi - два виртуальных модуля на каждом хосте и служба VSA Cluster Service на сервере vCenter.
3 хоста ESXi - на каждом по виртуальному модулю (3-узловому кластеру служба на vCenter не нужна)
С точки зрения развертывания VMware VSA - очень прост, с защитой "от дурака" и не требует каких-либо специальных знаний в области SAN (но во время установки модуля на хосте ESXi не должно быть запущенных ВМ)...
Компания StarWind Software, выпускающая самый лучший продукт для создания iSCSI-хранилищ для ваших серверов VMware vSphere и Mirosoft Hyper-V (см. тут и тут), объявила о выпуске решения StarWind Enterprise 5.7, которое предоставляет еще больше возможностей по созданию отказоустойчивых хранилищ (само собой, есть бесплатная версия StarWind 5.7 Free).
Этот релиз StarWind Enterprise 5.7 представляет собой первый шаг по переводу механизма отказоустойчивости хранилищ на новую архитектуру.
Перечислим основные новые возможности StarWind 5.7:
1. Улучшения механизма синхронизации. Теперь отсылка данных между узлами отказоустойчивого кластера происходит в асинхронном режиме. Это означает, что StarWind Enterprise HA теперь работает заметно быстрее. Подробности нового механизма работы HA вы можете прочитать в блоге у Константина, а мы приведем основную суть.
Ранее все работало следующим образом:
Когда iSCSI-пакет приходит на основной узел, он отправляет его на резервный. После того, как резервный узел получает пакет, он посылает iSCSI-команду подтверждения получения блока данных (ACK), только после получения которой основной узел передает ACK инициатору и записывает пакет на диск. Когда iSCSI-команд становилось много, они ставились в очередь и происходили некоторые задержки, поскольку постоянно нужно было совершать эти итерации.
Теперь все работает так (некий гибрид синхронного и асинхронного процессов):
Когда iSCSI-пакет приходит на основной узел, он отправляет его на резервный. И, не дожидаясь ACK от партнера, сразу посылается второй пакет. Когда очередь закончится, и второй узел запишет данные на диск, он отсылает ACK основному узлу, которые его уже передает инициатору. Так все работает значительно быстрее. Ну и защита от потери данных при сбое в канале синхронизации тоже есть.
2. Улучшения High availability. Появилось управление полосой пропускания канала синхронизации (QoS) - теперь можно регулировать приоритезацию трафика при синхронизации HA-узлов, что позволяет не забивать весь доступный канал и не затормаживать доступ к общему хранилищу. Для этого нужно выбрать пункт "Sync channel priorities" из контекстного меню HA-устройства.
По умолчанию для наибольшей безопасности приоритет стоит у канала синхронизации. Выставлять QoS нужно только на основном узле, на резервном он выставится автоматически.
3. Оптимизация канала. Теперь для оптимизации канала используется несколько параллельных iSCSI-сессий. В следующей версии StarWind Enterprise 5.8 это количество можно будет регулировать, а также возможна будет настройка количества каналов для Heartbeat.
4. Performance Monitoring - возможность отслеживания производительности дисковой подсистемы из Management Console (disk transfer rate, average number of I/O operations on targets, CPU and memory load on StarWind server). Выглядит это так:
5. Новая полезная оснастка - Snapshot Manager. Теперь можно управлять снапшотами через GUI. Для этого в контекстном меню для устройства нужно выбрать пункт "Snapshot Manager".
6. Улучшенный Event log. Теперь при наступлении события происходит нотификация администратора через иконку в System Tray.
7. Улучшения GUI. Теперь Targets и серверы могут объединяться в группы для удобства управления.
8. Экспериментальный "deduplication plugin". Он позволяет установить дедупликацию с размерами блока от 512Б до 256КБ на выбор (вместо 512Б сейчас), что позволяет увеличить производительность процесса дедупликации до десяти раз, при этом экономия пространства на дедупликации уменьшается всего на 10-15% (при сравнении 512 байтовых с 4кб блоками). Кроме того, значительно понизится нагрузка на ЦПУ и 90% уменьшятся требования к объёму ОЗУ.
9. ImageFile, DiskBridge. Поддержка режима Mode Sense page 0x3 для совместимости с iSCSI-инициатором Solaris.
Сан-Франциско, 12 июля 2011 г. – Сегодня, в рамках прямой трансляции из США Пол Мариц, президент и CEO компании VMware, представил новую платформу VMware vSphere 5 и полный пакет решений для облачных инфраструктур. С их помощью клиенты компании смогут трансформировать свои ИТ-системы, добиваясь большей эффективности инвестиций и повышения операционной гибкости. Таги:
Компания VMware в июле 2011 года объявила о доступности новых версий целой линейки своих продуктов для облачных вычислений, среди которых находится самая технологически зрелая на сегодняшний день платформа виртуализации VMware vSphere 5.0.
Мы уже рассказывали об основном наборе новых возможностей VMware vSphere 5.0 неофициально, но сейчас ограничения на распространение информации сняты, и мы можем вполне официально рассказать о том, что нового для пользователей дает vSphere 5.
Некоторые пользователи серверов хранения iSCSI на базе Microsoft iSCSI Target хотели бы перейти на StarWind Enterprise (тем более, что есть бесплатная версия StarWind). Но есть одна проблема - Microsoft iSCSI хранит свои данные в виде VHD-дисков, а у StarWind - формат IMG.
Специально для этого в StarWind и сделали утилиту StarWind V2V Converter, которая справляется с задачей конвертации VHD2IMG:
Оригинальные VHD тоже неплохо бы оставить в целях бэкапа.
Таги: StarWind, Enterprise, Migration, V2V, iSCSI, Storage, Microsoft
Мы уже писали о новых возможностях версии Citrix XenServer 6.0 "Project Boston", теперь же он доступна для свободного скачивания с сайта Citrix, при этом добавилось несколько новых функций.
Чуть более развернутое описание новых возможностей Citrix XenServer 6.0:
Product Simplification - Технологии Workload Balancing, StorageLink и Site Recovery полностью интегрированы в XenServer. Управление ими происходит через центральную консоль XenCenter, все виртуальные модули (virtual appliances) теперь построены на базе Linux и поставляются в соответствующих форматах VA (например, модуль Workload Balancing). Дистрибутив теперь поставляется на одном CD.
Architectural Changes - в качестве гипервизора используется доработанный Xen 4.1, включающий в себя распределенный коммутатор Open vSwitch (OVS), который используется по умолчанию. В Open vSwitch появились улучшения NIC Bonding (Teaming), поддержка Jumbo Frames. Говорится также об улучшении производительности сетевого взаимодействия до 70-100% для некоторых сценариев. Также есть поддержка SR-OIV и увеличена производительность сетевого взаимодействия (особенно для продуктов NetScaler VPX и SDX).
Self-Service & Cloud Building Tools - новая консоль Self-Service Manager позволит создавать окружения с сервисом самообслуживания пользователей (поставляется в виде виртуального модуля с веб-интерфейсом). Это что-то вроде облачного менеджера для частных облаков, который поддерживает платформы XenSever и VMware vSphere. Поддерживаются виртуальные модули OVF, возможность создавать многомашинные конфигурации (vApp) для использования с функциями HA и Site Recovery, а также возможность импорта виртуальных дисков VMware VMDK и Microsoft VHD.
Microsoft System Center Integration - Управление хостами XenServer и виртуальными машинами из System Center Virtual Machine Manager (VMM) 2012. Также предполагается мониторинг XenServer с помощью System Center Operations Manager 2012, на который будет накатываться специальными пакет от Citrix (подробности будут позже).
XenDesktop Enhancement & Improvements - Улучшения технологии HDX для оптимизации производительности виртуальных ПК и поддержка GPU Pass-Thru, что позволяет раздавать ресурсы видеоадаптера виртуальным машинам (поддержка как single GPU card, так и multi-card GPU card). Это все позволяет за счет технологии XenDesktop HDX 3D Pro улучшить поддержу CAD и требовательных к графике приложений.
Guest OS Support Updates - поддержка гостевых ОС Ubuntu 10.04, RHEL 5.6 и SLES 10 SP4. Экспериментальная поддержка Solaris и Ubuntu 10.10. Версии RHEL 6 и Debian Squeeze поддерживаются еще с XenServer 5.6 SP2.
Platform Enhancements & Improvements - мастер "Rolling Pool Upgrade" (упрощение миграции с 5.6 на 6.0), поддержка хранилищ NFS для высокой доступности (HA) и последовательности загрузки ВМ в случае сбоя, поддержка 1ТБ памяти хост-сервера, улучшенные параметры количества vCPU (16) и vRAM (128 ГБ) для виртуальных машин, улучшения NIC bonding (а также поддержка active/passive bonding).
Другие изменения - Self-Service Manager - это замена Lab Manager. Поддержка последнего еще некоторое время останется. Некоторые массивы перестали поддерживаться StorageLink, что проверяется при апгрейде с 5.6 на 6.0. Кроме того, теперь Site Recovery не зависит от технологии StorageLink, что позволяет более гибко подходить к созданию катастрофоустойчивых конфигураций на базе XenServer.
Сегодня мы поговорим о защите от несанкционированного доступа к различным компонентам инфраструктуры VMware vSphere с помощью vGate R2. Мы уже писали о том, как с помощью vGate R2 можно автоматически настроить vSphere в соответствии с политиками ИБ, а также обсуждали экономический эффект, а теперь углубимся в защиту от НСД...
Итак, конкурсная комиссия в лице меня и наиболее знающих вас сотрудников StarWind выбрала победителей. Итак, кто же получил модный девайс Amazon Kindle.
Мы уже писали о некоторых расширенных настройках дисковой подсистемы серверов VMware ESX / ESXi, которые позволяют управлять доступом виртуальных машин к хранилищам VMFS. Сегодня постараемся описать еще несколько параметров:
Опишем еще несколько параметров Advanced Settings для категории Disk:
Disk.MaxLUN - это число (по умолчанию 256, т.е. ID от 0 до 255), опеделяющее максимальное количество томов, доступных серверу VMware ESX / ESXi.
Disk.MaskLUNs = "vmhba1:0:32-35;vmhba2:0:1,5,7-9" - это параметр, определяющий маскирование томов VMFS в SAN. В данном примере от хоста ESX / ESXi скрываются LUN с ID от 32 до 35 для HBA-адаптера vmhba1, а также LUN с ID 1,5,7,8,9 для адаптера vmhba2. Разделитель для адаптеров - точка с запятой.
Disk.SupportSparseLUN - эта настройка включена по умолчанию (значение 1), по желанию ее можно выставить в 0. Значение 1 означает, что на ESX / ESXi включена поддержка номеров LUN, идущих непоследовательно (например, 0,6 и 23). Если у вас все LUN идут по порядку, то можно отключить эту функцию, выставив значение 0. В этом случае будет тратиться немного меньше времени на сканирование всех LUN.
Disk.DiskMaxIOSize - с помощью этого параметра можно задать максимальный размер операции ввода-вывода (IO request). По умолчанию, сервер VMware ESX / ESXi поддерживает объем IO-запроса размером до 32767 KB, запросы большего объема разбиваются на части. Для некоторых хранилищ (это надо смотреть в документации) такой размер IO-запроса, генерируемый некоторыми приложениями может оказаться слишком большим и привести к снижению производительности. Поэтому можно уменьшить этот параметр, в зависимости от модели дискового массива. Более подробно описано в KB 1003469.
Disk.SchedQControlVMSwitches - по умолчанию, этот параметр равен 6. Он означает вот что. Когда у нас несколько виртуальных машин отдают свои IO к LUN, у нас вступает в игру параметр Disk.SchedNumReqOutstanding (а не глубина очереди адаптера), который определяет границу для виртуальных машин по одновременной отдаче команд ввода-вывода. Если эта граница превышена - наступает постановка команд в очередь. Но VMkernel должен перед этим обнаружить, что LUN использует несколько ВМ. Так вот Disk.SchedQControlVMSwitches определяет сколько раз должен VMkernel это обнаружить. А понимает он это только тогда, когда следующее IO приходит не от той машины, которая дала предыдущий IO. Надо понимать, что это значение может быть достигнуто не очень скоро, когда у нас есть одна высоконагруженная ВМ A на одном LUN, и там же есть низконагруженная по IO машина (B). И это хорошо, поскольку в таких окружениях не должно быть урезания по вводу-выводу для высоконагруженной ВМ.
Disk.SchedQuantum - по умолчанию, этот параметр равен 8. Он определяет число высокоприоритетных последовательных команд, которые идут к дисковому устройству. Последовательными командами считаются те, которые идут к расположенным рядом секторам диска. Что такое расположенные рядом сектора диска? Это те, которые (по умолчанию) находятся друг от друга на расстоянии не более 2000 секторов. Такие команды выполняются до 10 раз быстрее, чем с далекими секторами.
Disk.SectorMaxDiff - это и есть параметр, определяющий, что такое "близкие" секторы для предыдущего параметра. По умолчанию, он равен 2000.
Disk.SchedQControlSeqReqs - этот параметр (по умолчанию, 128) определяет число последовательных IO без переключений (т.е. последовательность команд только от одной ВМ), после которых счетчик Disk.SchedQControlVMSwitches будет сброшен в 0, а машина сможет использовать опять всю очередь адаптера. Этот параметр нужен для того, чтобы после всплеска нагрузки на ВМ B в первом примере, когда этот всплеск прекратится, ВМ A снова смогла получить в свое распоряжение всю очередь адаптера и дальше работать в интенсивном режиме без входа в игру параметра Disk.SchedNumReqOutstanding, который распределяет IO на LUN.
Воткнули? Нет? Тогда еще раз перечитывайте статью Duncan'а. А еще один блоггер, Andy Grant, нарисовал замечательную картинку (кликабельно):
Как знают пользователи VMware vSphere, в версии платформы 4.1 появилась новая возможность по управлению приоритетами ввода-вывода виртуальных машин для хранилищ на уровне кластера под названием Storage IO Control (SIOC). Но эта функциональность доступна только в издании vSphere Enterprise Plus, что оставляет множество пользователей за бортом.
В рамках одного хост-сервера VMware ESX / ESXi есть механизм по управлению приоритетами ВМ для хранилищ с помощью Disk Shares (в настройках ВМ). Однако эти приоритеты могут быть заданы только в относительных значениях, что тоже в некоторых случаях неудобно.
В версии VMware vSphere 4.1 появилась возможность задать параметры ограничения ввода-вывода для конкретных ВМ с помощью абсолютных значений (в числе операций в секунду - IOPS и в пропускной способности в секунду - MBps). Это может пригодиться для отдельных виртуальных машин, для которых есть риск "забивания" канала к системе хранения.
Как можно эти параметры добавлять:
Нажмите Edit Settings для выключенной виртуальной машины.
Перейдите на вкладку Options.
В категории Advanced: General нажмите кнопку Configuration Parameters.
Нажмите Add Row.
Далее можно добавить 2 параметра (обратите внимание, что они задаются для каждого виртуального диска):
sched.<diskname>.throughputCap = <value><unit>
Например:
sched.scsi0:0.throughputCap = 10KIOps
sched.<diskname>.bandwidthCap = <value><unit>
Например:
sched.scsi0:0.bandwidthCap = 10KBps
В качестве значений можно использовать буквы K (KBps или KIOps), M (MBps или MIOps) и G (GBps или GIOps). Подробнее в KB 1038241.
По наблюдениям автора, если задать оба параметра для виртуального диска, они будут проигнорированы хост-сервером. А если для каждого диска одной ВМ задать определенные лимиты, то для каждого из этих дисков лимит установится как сумма для двух (то есть, если мы поставим 100IOps и 50IOps, лимит для каждого диска станет 150IOps).
Напоминаю, что работает это только, начиная с VMware vSphere 4.1 (и для ESX, и для ESXi).
StarWind Enterprise iSCSI Target в виде VSA позволит вам создать хранилища для виртуальных машин VMware vSphere или Microsoft Hyper-V в виде виртуальных серверов хранения (в ВМ), которые развертываются из уже готовой машины StarWind VSA. Для платформ ESX / ESXi и Hyper-V компания StarWind выпустила отдельные версии. Сам виртуальный модуль построен на базе Gentoo Linux и не требует отдельной лицензии Windows.
Отличительная особенность от аналогичных продуктов, поставляемых в виде виртуальных модулей (например, Openfiler) - это то, что с помощью этих модулей можно создать хранилища с высокой доступностью, которые в случае выхода из строя одного из узлов (т.е. ВМ или хост-сервера) мгновенно переключается на работу с синхронизированным резервным хранилищем.
О решении для создания хранилищ StarWind Enterprise iSCSI в виртуальных машинах мы уже писали тут. Его можно использовать для филиалов и небольших компаний, где нет возможности закупить дорогостоящие системы хранения данных, и даже нет денег на покупку отдельных серверов хранения.
Установка продукта StarWind VSA очень проста - вы импортируете виртуальный диск на хранилище VMware ESX или ESXi (понятное дело, что это может быть как локальный том VMFS, так и общее хранилище NFS/VMFS), создаете новую виртуальную машину, к которой подцепляете этот диск vmdk, а также еще один виртуальный диск для хранения данных виртуальных машин, которые будут защищены с помощью высокой доступности.
Конфигурацию машины StarWind VSA рекомендуется сделать такой (пока нет точной информации по этому поводу):
Guest OS - other Linux 64 bit
RAM - 1 GB
2 vNIC
можно поставить paravirtualized SCIS-контроллер для диска с данными
После загрузки этой машины, на стартовом скрине можно будет увидеть IP-адрес, полученный по DHCP, а дальше ее можно подцепить с помощью StarWind Management Console, где уже настраиваются сетевые и прочие параметры:
Процесс установки для платформы Hyper-V в принципе аналогичен. Понятное дело, когда выйдет релизная версия StarWind VSA, она будет поставляться в виде виртуального модуля OVF, чтобы машину можно было сразу импортировать на ESX.
Насчет логина и пароля к Linux-консоли StarWind VSA. Это vsa и starwind, соответственно. Для добавления VSA к консоли управления логин и пароль остались теми же: root и starwind.
Скачать StarWind VSA сейчас можно бесплатно и без регистрации с пробной лицензией на 120 дней по этой ссылке.
Как знают администраторы систем хранения данных, у различных компонентов SAN-сети есть такой параметр как глубина очереди (Queue Depth). Он есть у HBA-адаптера сервера (на котором, например, работает VMware ESX / ESXi) и у порта Storage Processor'а системы хранения (SP). Глубина очереди определяет сколько операций ввода-вывода (IO) может быть одновременно обработано на устройстве.
Как мы уже писали, если до SP со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (T) должна удовлетворять следующему соотношению:
T >= Q*L,
где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.
Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:
T>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.
Queue Depth на серверах
По умолчанию, для хостов VMware ESX / ESXi значение Queue Depth равно 32, как его изменить, читайте у нас тут и вот тут. Теперь внимание: этот параметр имеет значение только когда у вас только одна виртуальная машина на хост-сервере использует конкретный LUN. Если его используют уже 2 машины, то он игнорируется, а в действие вступает следующая расширенная настройка (Advanced Setting - как его задавать описано тут):
Disk.SchedNumReqOutstanding (DSNRO)
Этот параметр также по умолчанию равен 32. Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN. То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в статье Jason Boche, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32:
Здесь видно, что активно выполняется 30 команд (максимально 32) для параметра DQLEN, а остальные 67 остаются в очереди. То есть параметр определяет максимальную планку в IO как для одной машины на LUN, так и для всех машин на LUN.
Важно, чтобы параметры Queue Depth и DSNRO были установлены в одно и то же значение. Это рекомендация VMware. Так что, если вздумаете изменить один из них - не забудьте и про второй. И помните, что параметр DSNRO для хоста - глобальный, а значит будет применяться ко всем LUN, подключенным к хосту.
Target Port Queue Depth на массивах
Для дискового массива (а точнее, SP) очередь - это то, куда он сладывает SCSI-команды в то время, пока обрабатывается и выполняется пачка предыдущих. Нормальный midrange-массив имеет глубину очереди 2048 и более. Если массив получает в очередь команд IO больше значения Target Port Queue Depth, то он назад выдает команду QFULL, которая означает, что очередь заполнена и хост-серверу нужно с этим что-то делать. VMware ESX / ESXi реагирует на это следующим образом - он уменьшает очередь на LUN и периодически (каждые 2 секунды) проверяет, не исчезло ли QFULL, и если исчезло, то начинает постепенно увеличивать глубину очереди для этого LUN (это может занять до одной минуты). Это и есть причины тормозов, которые часто возникают у пользователей VMware ESX / ESXi.
Как управлять очередью и адаптивный алгоритм VMware
Теперь становится понятным, почему мы сразу не выставляем параметр Disk.SchedNumReqOutstanding на хостах VMware ESX / ESXi в максимальное значение - мы можем вызвать QFULL на SP массива. С другой стороны, уменьшать его тоже нехорошо - мы ограничим количество операций IO с хоста на LUN.
Поэтому здесь нужен гибкий подход и он есть у VMware (adaptive queue depth algorithm). Работает он таким образом: мы его активируем с помощью параметров Disk.QFullSampleSize и Disk.QFullThreshold в Advanced Settings. Они влияют вот на что:
QFullSampleSize - если число число ответов QFULL (оно же BUSY) превысит его, то ESX / ESXi наполовину обрежет глубину очереди (LUN queue depth)
QFullThreshold - если число ответов о том, что QFULL или BUSY больше нет, превысит его, то ESX / ESXi будет постепенно увеличивать LUN queue depth на 1 (вроде бы, каждые 2 секунды).
Но сколько бы не уменьшалось DQLEN - ниже заданного нами значения DSNRO оно не упадет. Это защищает нас от неожиданного провала в производительности. Кстати, эти параметры тоже глобальные - так что если один (например, тормозящий) массив с хоста будет подвергаться такому адаптивному эффекту со стороны ESX / ESXi, то и для другого (например, производительного) тоже будут выполняться такие фокусы.
Теперь, что дополнительно можно почитать на эту тему:
То есть мораль всей басни такова - дефолтные зачения DSNRO и Queue Depth подходят для большинства случаев. Но иногда имеет смысл изменить их. Но в этом случае надо учитывать параметры системы хранения данных, структуру SAN, количество LUN и другие параметры, влияющие на производительность ввода-вывода.
А сегодня мы расскажем вам еще об одной бесплатной утилите StarWind под названием RAM Disk Emulator (Virtual RAM Drive). Это средство для создания RAM-дисков, то есть виртуальных дисков, выглядящих как локальные в системе, но созданные на основе участка оперативной памяти. Само собой, такие диски на порядок быстрее обычных.
Так как при выключении компьютера такие диски пропадают, то их удобно использовать, например, при работе с расшифрованными копиями зашифрованных файлов (после выключения диск очистится).
RAM Disk Emulator прост в использовании. Устанавливаете, создаете новый диск с заданным объемом (максимум 1024 МБ для одного диска, дисков может быть несколько) и все. Можно поставить настройки форматирования RAM-диска и параметры его монтирования в ОС.
И напоследок. Костян, мой добрый товарищ из StarWind, завел блог о технических вопросах, касающихся StarWind Enterprise. Заходим: http://constantinv.posterous.com.
На сайте VMware Communities появилась в открытом доступе для всех желающих бета-версия продукта VMware Converter Standalone 5.0, предназначенного для миграции физических серверов в среду VMware vSphere, перевода виртуальных машин на эту платформу с решений других производителей (Hyper-V), а также для миграции между платформами VMware (Workstation, Server, Fusion). Слово Standalone в названии продукта означает, что он не интегрирован с консолью vSphere Client при подключении к vCenter и имеет свой собственный интерфейс управления. Напомним, что продукт абсолютно бесплатен.
Напомним также, что последняя мажорная версия VMware Converter вышла аж в 2009 году (см. нашу заметку тут, а также про версию 4.3 - тут). Поэтому данное обновление - весьма долгожданное.
Новые возможности VMware Converter 5.0:
Сохранение LVM-конфигурации томов исходной Linux-машины при ее миграции.
Улучшенный механизм синхронизации, включая запланированный запуск задачи, а также выполнение нескольких задач синхронизации в одной задаче миграции.
Оптимизация выравнивания дисков и разделов + возможность изменения размера кластера ФС.
Передаваемые данные при миграции между исходным сервером и сервером назначения - шифруются.
Поддержка миграции Red Hat Enterprise Linux 6.x (32-bit and 64-bit). Прекращена поддержка Ubuntu 5.x-7.x.
Скачать бету VMware Converter Standalone 5.0 можно по этой ссылке. Документация доступна тут.
Как оказалось, на нашем сайте нет хорошего руководства по назначению и использованию RDM-дисков (Raw Device Mapping) с платформой VMware vSphere. Постараемся заполнить этот пробел.
Давайте начнем с того, что для виртуальных машин на серверах VMware ESX есть всего 3 типа дисков с точки зрения виртуализации подсистемы хранения:
VMDK-диски
Это самые часто используемые диски VMware vSphere. Они создаются на хранилищах VMFS или NFS и позволяют использовать все возможности работы VMware с виртуальными машинами в части распределенных служб. К ним относятся распределенная блокировка файлов (distributed file locking), снапшоты дисков, vMotion - и много чего еще. О типах виртуальных дисков у нас есть отдельная статья. Обычные vmdk-диски - это самый высокий уровень виртуализации, т.е. все SCSI-команды виртуальной машины при обращении к нему проходят через компонент VMkernel, который уже процессит их внутрь файла vmdk. За пределы этого файла виртуальная машина ничего не видит. То есть виртуальной машине дается кусочек тома VMFS или NFS в виде файла vmdk, операции по работе с которым полностью контролируются гипервизором - это и есть максимальная виртуализация устройства. Из этого, кстати, следует, что поскольку есть слой виртуализации, в определенных условиях такие диски могут работать медленнее RDM-дисков, но есть также и условия при которых такие диски могут работать быстрее. Более подробно об этом можно прочитать здесь. На этих дисках в статье мы останавливаться не будем.
RDM-диски в режиме виртуальной совместимости (virtual RDM).
Это промежуточный тип диска с точки зрения виртуализации хранения. В случае создания такого диска на хранилище VMFS (NFS - не поддерживается) создается mapping-файл (он тоже с расширением *-rdmp.vmdk), через который происходит маппирование виртуальной машине физического дискового устройства LUN. Устройство это маппируется особым образом - основные служебные операции по работе с ним (например, команда Open и другие служебные SCSI-команды) проходят через через слой виртуализации в гипервизоре, а команды по работе с данными (Read и Write) процессятся напрямую к устройству, минуя слой виртуализации.
Что означает, что передаются напрямую только команды Read / Write в виртуальный RDM? Это означает, что устройство представляется виртуальной машине как обычный SCSI-диск, с которым нельзя работать иначе как с устройством хранения (как можно иначе - дальше). Зато сохраняется большинство возможностей VMware vSphere по функциональности - например, снапшоты. Ниже мы также посмотрим, где можно использовать такой тип дисков.
RDM-диски в режиме физической совместимости (Physical RDM). Это наименее виртуализованный тип дисков. Для таких дисков хост-сервер ESX также создает mapping-файл, но вот iSCSI-команды процессятся к устройству LUN напрямую, минуя слой виртуализации хранилища в гипервизоре (за исключением одной команды LUN Report).
Что дает такой механизм доступа к устройству? Он позволяет использовать iSCSI-устройство не просто как диск, но и передавать к нему различные iSCSI-команды, которые предоставлют больше возможностей по работе с устройством (например, управление SAN-устройствами изнутри виртуальной машины или снятие снапшота на уровне хранилища). Ниже мы тоже рассмотрим подобные примеры.
Насколько я знаю, многие из вас используют продукт StarWind Enterprise iSCSI, который позволяет создать отказоустойчивое хранилище для виртуальных машин VMware vSphere и Microsoft Hyper-V (см. наш раздел о StarWind). Совместно со StarWind мы проводим конкурс на лучшее предложение по новым возможностям и функциям продукта. Призом станет Amazon Kindle - стильная читалка электронных книг с технологией E-Ink и модулем Wi Fi.
Вы уже все знаете про продукт StarWind Enterprise iSCSI (но еще не все купили), который позволяет создавать отказоустойчивые хранилища для виртуальных машин VMware vSphere и Microsoft Hyper-V (у нас есть, кстати, специальный раздел о StarWind). Недавно мы писали о том, что вышла бесплатная версия StarWind Free.
А сегодня еще одна приятная новость для задумавшихся о покупке продукта - теперь StarWind Enterprise полностью сертифицирован со стороны VMware в качестве системы хранения по программе VMware Certified Partner. Вы можете обнаружить его в HCL-листе:
Из пресс-релиза:
StarWind iSCSI SAN software has successfully passed all the laboratory tests and has met all the interoperability criteria required by VMware.
This certification assures our customers that StarWind solution is officially compatible with VMware virtualization products and guarantees full VMware technical support for any VMware infrastructure built using StarWind iSCSI SAN.
Так что теперь можете смело показывать руководству, что iSCSI-хранилища StarWind Enterprise - это сертифицированное VMware решение.
Начните хотя бы с бесплатной версии - это не потребует от вас ничего кроме обычного Windows-сервера, который даже может быть виртуальным. Кстати, скоро выйдет версия StarWind Enterprise 5.7, где будет еще больше возможностей.
Новые возможности, которые появятся в Citrix XenServer 6.0:
Product Simplification - Технологии StorageLink и Site Recovery полностью интегрированы в XenServer. Управление ими происходит через центральную консоль XenCenter, все виртуальные модули (virtual appliances) теперь построены на базе Linux и поставляются в соответствующих форматах VA.
Architectural Changes - в качестве гипервизора используется доработанный Xen 4.1, включающий в себя распределенный коммутатор Open vSwitch, который используется по умолчанию. Также есть поддержка SR-OIV и увеличена производительность сетевого взаимодействия.
Self-Service & Cloud Building Tools - новая возможность Self-Service Manager позволит создавать окружения с сервисом самообслуживания пользователей. Поддерживаются виртуальные модули, возможность создавать многомашинные конфигурации для использования с функциями HA и Site Recovery, а также возможность импорта виртуальных дисков VMware VMDK и Microsoft VHD.
Microsoft System Center Integration - Управление хостами XenServer и виртуальными машинами из System Center Virtual Machine Manager (VMM) 2012. Также предполагается мониторинг XenServer с помощью System Center Operations Manager 2012, на который будет накатываться специальными пакет от Citrix (подробности будут позже).
XenDesktop Enhancement & Improvements - Улучшения технологии HDX для оптимизации производительности виртуальных ПК и поддержка GPU Pass-Thru, что позволяет раздавать ресурсы видеоадаптера виртуальным машинам (поддержка как single GPU card, так и multi-card GPU card).
Guest OS Support Updates - поддержка гостевых ОС Ubuntu 10.04, RHEL 5.6 и SLES 10 SP4. Экспериментальная поддержка Solaris и Ubuntu 10.10. Версии RHEL 6 и Debian Squeeze поддерживаются еще с XenServer 5.6 SP2.
Platform Enhancements & Improvements - мастер "Rolling Pool Upgrade", поддержка хранилищ NFS для высокой доступности (HA), поддержка 1ТБ памяти хост-сервера, улучшенные параметры количества vCPU и vRAM для виртуальных машин, улучшения NIC bonding.
Скачать XenServer "Project Boston" Beta можно по этой ссылке.
Интересные новости от компании Veeam Software, лидера по производству средств управления виртуальной инфраструктурой VMware vSphere. Как вы знаете, Veeam выпускает очень успешный продукт Veeam Backup and Replication, который осуществляет резервное копирование, восстановление и репликацию виртуальных машин виртуальной инфраструктуры VMware vSphere. По статистике, первое, что пользователи приобретают после VMware vSphere - это Veeam Backup.
Какими возможностями будет обладать Veeam Backup for Microsoft Hyper-V:
2-in-1 backup and replication for Hyper-V: как и для VMware vSphere, Veeam Backup будет уметь делать репликацию виртуальных машин между хост-серверами для создания недорогой инфраструктуры отказоустойчивости и сокращения времени восстановления после сбоя (RTO).
Changed block tracking for Hyper-V: Veeam будет поддерживать технику Changed Block Tracking, которая позволяет отслеживать изменяющиеся блоки хранилищ (в данном случае тома CSV), что позволит наиболее быстро делать инкрементальные резервные копии.
Built-in deduplication and compression: будут включены функции по дедупликации блоков хранимых резервных копий и функция компрессии для ускорения передачи данных по сети.
Veeam Backup для пользователей Microsoft Hyper-V ожидается в четвертом квартале 2011 года.
Практически одновременно с выпуском платформы для виртуализации Citrix XenDesktop 5 Service Pack 1 компания Citrix выпустила также и обновленную версию своей серверной платформы Citrix XenServer 5.6 Service Pack 2. Причина одновременности обновлений - поддержка в XenServer 5.6 SP2 технологии IntelliCache, которая оказывает существенное влияние на работу виртуальных ПК.
Напомним, что в первом Service Pack (а точнее Feature Pack 1) было множество интересных возможностей. Теперь же появились следующие нововведения:
IntelliCache. С помощью этой технологии можно снижать стоимость обслуживания инфраструктуры виртуальных ПК за счет использования комбинации общего и локального хранилища для виртуальных машин (см. описание ниже).
WorkLoad Balancing Installation Improvements. Появились улучшения в мастере установки этого компонента.
Local Storage Spans All Physical Volumnes. Когда используется локальное хранилище для виртуальных ПК, на хосте с несколькими физическими дисками в компоненте local Storage Repository (SR) все диски объединяются в единую группу LVM.
Reset-on-boot VM behaviour. Диски с опцией on-boot, установленной в значение reset, теперь доступны в качесве дисков для любого типа хранилища (ранее это было доступно только для дисков NFS и EXT SRs).
Block SCSI Generic Support. За счет поддержки BSG обеспечивается полная совместимость со средствами управления Emulex и QLogic.
Enhanced guest OS support. Поддержка гостевой ОС Red Hat Enterprise Linux (RHEL) 6.
Что такое IntelliCache в Citrix XenServer?
Идея такова: поскольку при использовании виртуальных ПК на базе одного базового образа генерируется большая нагрузка на общую систему хранения по вводу-выводу, нужно как-то разобраться с этой проблемой, тем более, что она приводит в том числе к VDI Boot Storm. Так вот предлагается поместить базовый образ виртуального ПК на недорогое NAS / NFS хранилище, а потом осуществлять кэширование этого образа на локальных дисках хоста XenServer для максимальной производительности связанных клонов виртуальных ПК, использующих этот образ. Кэш IntelliCache может располагаться как на локальном диске (рекомендуется SSD), так и в оперативной памяти на RAM-диске. Есть мнения, что 200-мегабайтного кэша хватает на устранения последствий VDI Boot Storm для инсталляций порядка 50 ВМ на хосте.
Скачать Citrix XenServer Service Pack 2 можно по этой ссылке.
Теперь у вас есть полностью бесплатный StarWind iSCSI Target, чтобы создавать хранилища для виртуальных машин на базе существующей Ethernet-инфраструктуры и без каких-либо вложений. Дальше уже можно задуматься о коммерческом издании StarWind CDP или средстве создания отказоустойчивых хранилищ StarWind Enterprise HA.
Новая бесплатная версия StarWind Free Edition позволит вам использовать многие серьезные возможности, которые есть только у коммерческих продуктов:
Любую современную хостовую операционную систему Windows Server для сервера хранилища. Можно использовать локальные диски серверов для создания томов VMFS с поддержкой VMware HA/DRS и других распределенных служб.
Можно создавать хранилища для виртуальных машин VMware vSphere, Microsoft Hyper-V, Citrix XenServer и других систем виртуализации.
Дедупликация данных (с различными размерами блоков). Это позволяет экономить дисковое пространство на системе хранения, убирая дублированные блоки.
Полностью разрешенное лицензией использование хранилищ в производственной среде.
Поддержка! Для бесплатной версии идет basic support plan, что подразумевает поддержку через форум на сайте. Далее можно покупать поддержку по инцидентам, а также переключиться на любое коммерческое издание без дополнительных доплат (в платите только разницу между изданиями).
Caching - в StarWind iSCSI есть хороший механизм кэширования (write-back и write-through), ускоряющий работу виртуальных машин с хранилищами.
Функции VTL (Virtual Tape Library) и репликация по сети WAN доступны как возможность платного обновления на коммерческую версию.
Поддержка возможностей Thin Provisioning в StarWind - ваше хранилище для виртуальных машин (образ виртуального диска) будет расти по мере наполнения его данными.
В самом конце прошлого года компания Citrix выпустила новое поколение продукта для виртуализации корпоративных ПК предприятия (VDI) Citrix XenDesktop 5. Совсем недавно вышло обновление Citrix XenDesktop 5 Service Pack 1, которое, помимо множественных исправлений ошибок, имеет несколько новых возможностей.
Новые возможности Citrix XenDesktop 5 Service Pack 1:
Поддержка серверной платформы виртуализации XenServer 5.6 Service Pack 2, включая поддержку технологии IntelliCache
Поддержка Microsoft SC VMM R2 Service Pack 1 и Windows Server 2008 R2 Service Pack 1, Hyper-V 2008 R2 Service Pack 1, а также Windows 7 Service Pack 1.
Поддержка VMware VSphere 4.1 Update 1 в качестве хост-платформы для виртуальных ПК.
Улучшения в механизме лицензирования (модель "пользователь или устройство") - более гибкое управление имеющимися лицензиями.
Новые утилиты для осуществления миграции с платформы XenDesktop 4
Новый мастер установки для служб Citrix Provisioning Services, который позволяет развертывать виртуальные ПК в инсталляции XenDesktop 5.
Управление питанием для блейд-серверов с поддержкой сторонних плагинов для управления питанием.
Напомним, что Citrix XenDesktop 5 поставляется в 4-х изданиях: Express (бесплатно для 10 пользователей), VDI (только для виртуальных ПК, без виртуализации приложений), Enterprise (с XenApp Enterprise) и Platinum (с XenApp Platinum, соответственно).
Кроме того, пользуясь случаем передаем ответ на самый популярный вопрос по Citrix XenDesktop.
Q: Если я купил XenDesktop в редакции Enterprise или Platinum, то виртуализованные приложения XenApp можно запускать только из виртуальных ПК XenDesktop?
A: В этом случае в состав XenDesktopвходит полноценный XenApp, приложения можно публиковать для любых пользователей, не только для виртуальных ПК. Разница только в системе лицензирования – в составе XenDesktopваш XenAppлицензируется по общему количеству пользователей или устройств, а если покупать его отдельно, то по количеству одновременных подключений.
Издания Citrix XenDesktop 5 SP1 отличаются следующими возможностями:
Licensing
Express
VDI
Enterprise
Platinum
Named User Licensing
10 users
Device based licensing
Concurrent User Licensing
Component
Controller
Limited 1
XenServer 2
XenServer 3
XenServer, Enterprise Edition 4
XenServer, Enterprise Edition 4
XenServer, Enterprise Edition 4
Receiver
Desktop Studio
Machine Creation Services
Desktop Director
Workflow Studio
Profile management
StorageLink
Access Gateway 5
Platform License
Platform License
Universal License
XenApp
Enterprise
Platinum
XenVault
Provisioning services for desktops6
Provisioning services for servers
XenClient and Synchronizer
EdgeSight for Virtual Desktops
Branch Repeater 7
Single Sign-on
Скачать Citrix XenDesktop 5 Service Pack 1 можно по этой ссылке.
Это, по-сути, средство сбора отчетности о виртуальной инфраструктуре VMware vSphere и виртуальных машинах, что-то вроде бесплатного Veeam Reporter Free.
В категории Performance мы можем увидеть следующую информацию:
Host/VM Utilization Heat Map - в этой категории представлены хосты и виртуальные машины с наибольшей загрузкой вычислительных ресурсов. Весьма полезно для развертывания новых ВМ.
Host Top CPU Ready Queue - параметры метрики производительности CPU Ready. Подробнее об этом счетчике тут.
Storage Access IOPS - здесь мы видим нагрузку на виртуальные хранилища по IOPs (на и из Datastore).
В категории Efficiency мы можем увидеть следующую информацию:
VM Over/Under Provisioning - показывает недогруз или перегруз по ресурсам для виртуальных машин на хост-серверах.
Storage Wasted Allocations - ранжированно показывает, где у нас на хранилище лежит непойми что (не относящееся к ВМ) и их недозаполненность.
Storage Allocated to Dormant VMs - показывает какие ВМ не используются и сколько выделено под них хранилища.
VM Rightsizing Recommendations - показывает рекомендации по сайзингу ВМ с точки зрения производительности (типа добавить или удалить vCPU).
Но этот продукт для небольшой инфраструктуры, а нормальные пацаны с табуном серверов ESX / ESXi скачивают и покупают продукт Veeam Reporter, который позволяет вести трекинг изменений виртуальной инфраструктуры VMware vSphere и получать отчетность обо всех ее аспектах. Тем более, что недавно вышел бесплатный аддон к нему - Capacity Planning Report pack for Veeam Reporter.
Скачать же бесплатный VMTurbo Performance and Efficiency Reporter можно по этой ссылке.
Продолжаем рассказывать о решении StarWind Enterprise, которое позволяет вам создать отказоустойчивое iSCSI-хранилище для виртуальных машин на базе существующей Ethernet-инфраструктуры (то есть, с наименьшими вложениями).
Посмотрим, что продукт умеет в плане отслеживания различных событий, что полезно администратору. Во-первых, у нас есть вкладка Events, где отображаются наиболее значимые события сервера хранения StarWind iSCSI:
Во-вторых, у нас есть возможность смотреть логи сервера StarWind прямо из GUI с возможностью выбора лога:
Логи можно гибко настраивать:
В-третьих, мы можем настроить оповещения о различных событиях по e-mail:
В-четвертых, в версии StarWind 5.7 появились нотификации в системном трее:
Они тоже настраиваются:
Правда вот, по WMI и SNMP StarWind пока события не отдает, но это обещано в следующих релизах.
Как вы знаете, VMware vSphere 5 будет построена только на базе гипервизора VMware ESXi (а ESX больше не будет) и выйдет уже в этом году, поэтому мы публикуем серию заметок о том, как перейти на ESXi с ESX (вот тут - раз и два).
Сегодня мы поговорим о таком различии, как Scratch Partition в ESXi. Scratch Partition - это специальный раздел на хранилище для хост-сервера, который не обязательно, но рекомендуется создавать. Он хранит в себе различную временную информацию для ESXi, как то: логи Syslog'а, вывод команды vm-support (для отправки данных в службу поддержки VMware) и userworld swapfile (когда он включен). Он создается, начиная с vSphere 4.1 Update 1 автоматически, и, если есть возможность, на локальном диске.
Так как данный раздел является необязательным, то в случае его отсутствия вся перечисленная информация хранится на ramdisk хост-сервера (который, кстати, отъедает память - 512 MB). И, так как это ramsidk, после перезагрузки эта информация (если у вас нет scratch partition) очищается. Поэтому неплохо бы этот раздел, все-таки, создать.
По умолчанию, этот раздел создается в системе vfat и составляет 4 ГБ. Это много. Почему так много? Объяснение такое, что местечко оставлено под будущие версии ESXi. Этот раздел может размещаться локально или на SAN-хранилище. При этом его могут использовать несколько хостов ESXi одновременно, поэтому рекомендуется сделать его гигов 20. Но для каждого должна быть своя locker-директория на этом разделе.
Через vSphere Client scratch partition настраивается так:
Соединяемся с хостом ESXi из vSphere Client.
Переходим на вкладку Configuration.
Переходим в категорию Storage.
Нажимаем правой кнопкой на datastore и выбираем Browse.
Создаем уникальную директорию для хоста ESXi (например, .locker-ESXiHostname)
Закрываем Datastore Browser.
Переходим в категорию Software.
Нажимаем Advanced Settings.
Переходим в раздел ScratchConfig.
Устанавливаем в качестве значения ScratchConfig.ConfiguredScratchLocation директорию, которую только что создали, например:
/vmfs/volumes/DatastoreName/.locker-ESXiHostname
Нажимаем OK.
Перезагружаем ESXi.
Все это можно настроить и при автоматизированном развертывании VMware ESXi через kickstart. А можно и через vCLI и PowerCLI. О том, как это сделать, читайте в KB 1033696.
Слышали про такую проблему VDI Boot Storm? Вот у вас есть инсталляция системы виртуализации корпоративных ПК предприятия (например, на базе VMware View 4.x) на несколько десятков или даже сотен пользователей виртуальных ПК. В 8:00 у вас начинается рабочий день - пользователи приходят за свои рабочие места и одновременно включают свои виртуальные десктопы. В результате возникает серьезная нагрузка на систему хранения, где эти самые образы виртуальных ПК хранятся (десятки, сотни машин на сторадже).
И получается вот такой VDI Boot Storm - машины тормозят, сессии отваливаются, пользователи жалуются. Ведь при загрузке Windows 7 генерирует где-то 50-100 IOPS, а при обычной офисной работе это значение составляет 5-15 IOPS. Наглядно это выглядит так:
Что же делать с этим VDI boot storm?
Ну, во-первых, вы должны это обязательно учитывать при планировании развертывания инфраструктуры виртуальных ПК. Ваша инфраструктура хранения FC или iSCSI должна учитывать такие пиковые нагрузки, и начало рабочего дня - отличный способ это проверить. Есть также вот инструмент VDI Sizing Tool (VST) от нашего соотечественника, который позволяет мерить нагрузку для VDI-сценариев.
Во-вторых, SSD-диски. Да, дорого. Но иногда без них нельзя. Если вы используете VMware View с функциональностью View Composer для создания связанных клонов виртуальных ПК на основе базового образа - вам поможет концепция ярусного хранения данных, реализованная в продукте. На быстрые SSD-накопители можно помещать реплики пулов виртуальных ПК и Disposable-диски виртуальных машин. Сравните 150-200 IOPS у SAS-дисков с 5000 у SSD.
В-третьих, есть специализированные решения, такие как, например, NSS SAN Accelerator for VMware View. Эта штука представляет собой железку с SSD-дисками, которая ставится между хост-серверами VMware ESX / ESXi и системой хранения. Она умеет автоматически кэшировать наиболее часто используемые блоки и выравнивать нагрузку по хост-серверам.
В четвертых, есть мысль, что перед тем, как пользователь пришел на работу, его виртуальный ПК уже должен быть готов к работе и запущен. Мысль самая разумная, но почему-то нормальная настройка этого механизма в VMware View отсутствует. Вроде как даже из интерфейса View 4.5 убрали шедулинг запуска виртуальных ПК. А какого-то централизованного механизма вроде нет. Или есть? Может вы подскажете?
RSS
Постоянные читатели VM Guru знают о том, что мы с нашим спонсором, компанией StarWind Software, проводили конкурс среди вас на "
Насколько я знаю, многие из вас используют продукт 
10 users
